Aminet 15

home *** CD-ROM | disk | FTP | other *** search

/ Aminet 15 / Aminet 15 - Nov 1996.iso / Aminet / comm / fido / fnews3.lzh / fido307.nws < prev next >

Wrap

Text File | 1986-02-16 | 48KB | 1,321 lines

Volume 3, Number 7 17 February 1986 +----------------------------------------------------------+ | _ | | / \ | | - Fidonews - /|oo \ | | (_| /_) | | Fido and FidoNet _`@/_ \ _ | | Users Group | | \ \\ | | Newsletter | (*) | \ )) | | ______ |__U__| / \// | | / FIDO \ _//|| _\ / | | (________) (_/(_|(____/ | | (jm) | +----------------------------------------------------------+ Editor in Chief: Thom Henderson Chief Procrastinator Emeritus: Tom Jennings Fidonews is published weekly by SEAdog Leader, node 1/1. You are encouraged to submit articles for publication in Fidonews. Article submission standards are contained in the file FIDONEWS.DOC, available from node 1/1. Disclaimer or don't-blame-us: The contents of the articles contained here are not our responsibility, nor do we necessarily agree with them. Everything here is subject to debate. Table of Contents 1. EDITORIAL IFNA and You 2. ARTICLES Software Tools in Pascal available on Fido 143/12 Exploring MSDOS file structures Where Oh Where Can that Interrupt Be? Announcing two new newsletters Encryption, Public Keys and Otherwise XMODEM protocol benchmark 3. COLUMNS Notes from Abroad 4. FOR SALE DEC 11/23 Minicomputer for sale Entertainment Software for your PC! File Security and Secret*File 5. NOTICES The Interrupt Stack Higher Education Net proposed New Host for MetroNet Orange County is no longer part of SoCalNet New Version of Rovermsg Available ============================================================ EDITORIAL ============================================================ IFNA and You IFNA? Wazzat? Well, maybe I should explain a bit first. There's been some idle chatter (idle typing?) lately about IFNA, but most people probably don't know what it's all about. For that matter, nobody really knows what it's all about yet, because it doesn't exist yet. At the moment, it is nothing more than a dream. Ken Kaplan and Ben Baker have been coordinating FidoNet activities for quite some time now. I'm not sure just how long, since they started doing it before I joined the net, and well before I started editing this newsletter. In all that time they've seen it grow from a handful of hobbyists to a major electronic mail system. Yes, yes, I'm talking about the FidoNet we all know and love. You may not realize it, but we (all of us, you too) are now running an international network on par with the major commercial nets. We're getting noticed, too. Refer- ences to Fido and FidoNet are becoming more and more common in the trade journals. We're also a public service, now. Those articles about FidoNet for the deaf and blind weren't just hot air. There are deaf people right now using FidoNet as a means to contact the rest of the world. Even this modest little publication is becoming widely read among those in the know, much to my surprise. Awhile back an article here stimulated, in a matter of days, a response by phone from the president of a major corporation (I won't say who, except to note that it's a Fortune 500 company), just to mention one incident. I must admit that I am not used to having my words quite so widely read, immortal prose though they may be. But back to Ken and Ben. They've watched all this grow, and have been thinking (and worrying) about how to handle it if it keeps growing. Perhaps I should say "when it grows even larger", as it shows every sign of growing bigger and bigger as time goes by. One thing they saw right off. FidoNet would soon (say about last Tuesday) get big enough that it would require someone working full time to hold it all together. This is no sur- prise to me; I've seen much the same situation in other groups I belong to. The big question, of course, is how to finance such a thing, particularly without reducing or charging for the many services we already enjoy. Fidonews Page 2 17 Feb 1986 This is where the International FidoNet Association (IFNA) comes in. The general idea is to set up a not-for-profit service organization to provide services to FidoNet sysops and users. There are three main ways that this can be financed: 1. Voluntary contributions from individuals and corpora- tions. There is a trickle of this now, and we can expect it to grow once IFNA is registered as a non- profit organization. 2. Fees for new services not currently provided, such as the printed FidoNet magazine. 3. Fees for providing commercial services to outside companies. As you can see, they're trying to come up with ways of paying for our hobby that don't call for coercing anyone into paying for things they don't want. Probably all three methods will be used, but the one that really interests me is number three. One example I've heard of it is collecting data for market research companies. The general idea is that participating sysops use the question- naire ability of Fido to collect the data, which is then sent to a central collection point that bills the outside company. Participating sysops get money back, depending on the amount of data collected. Sysops who don't want to participate don't have to. And THAT I like. Nobody is forced to do anything they don't want, and everybody has a chance to make a few bucks while helping out. All winners, no losers. That's really the whole point of IFNA, to figure out ways to benefit everyone on the net. ------------------------------------------------------------ Fidonews Page 3 17 Feb 1986 ============================================================ ARTICLES ============================================================ Programs From "Software Tools in Pascal" Now Available on the Wyrld Wyrm BBS, Fido 143/12 "Software Tools in Pascal", by Kernighan and Plauger (Addison-Wesley, 1981, $16.95) is a book on programming techniques that demonstrates good coding by building up a set of useful programming tools. These include an editor, a find-and-replace utility, a text formatter, and a number of smaller utilities, all useful. The authors have granted permission for noncommercial use and distribution of the software presented in the book. A version of the software, modified slightly to run under Turbo Pascal, appeared on the USENET (in mod.sources) a few months ago. These files, (edited slightly by me to eliminate a few glaring bugs) are available on my BBS, the Wyrld Wyrm BBS, Fido 143/12 (408) 263-8134. My BBS run 22 hours per day, with the two hours between 00:30 and 2:30 taken up by FidoNet. The file is about 50k long, and can be downloaded in under ten minutes at 1200 baud. While the programs are useful in themselves, they're invaluable as a Pascal source code library. Many routines that people tend to reinvent (sorting, string searching, etc.) are right there for the taking. I should warn you, though, that you'll need the book if you want to use these programs. The command line syntax, while simple, isn't obvious, and the person who typed in all the code left out the comments (assuming that you had the book in front of you, I suppose). The book is really good, though, so it's money well spent. -- Robert Plamondon Sysop, Wyrld Wyrm BBSs Fido 143/12 ------------------------------------------------------------ Fidonews Page 4 17 Feb 1986 Richard A. Karas Fido 107/29 Exploring MSDOS File Structures Disks (floppy as well as hard) are formatted or initialized under MSDOS Version 2.0 to allow fast and convenient access to files. MSDOS supports several methods of accessing files. The handle method, the File Control Block method, and the direct access method through directory and the File Allocation Table (FAT) search. The handle and FCB methods require you to access files through the operating system and their respective function calls, while the direct method enables you to access files as it implies, directly. To access files directly, a little knowledge of the way MSDOS formats the disk is required. MSDOS disks after formatting contain the following structures in sequence: o Reserve boot loader area. o First copy of the FAT. o Second copy of the FAT (for recovery purposes). o Root directory. o Data area. Utility programs read the reserved boot area where disk media data may be found. This data provides the program with information about the device. Typically byte offsets 11 through 29 have been set aside to define all the necessary attributes required. Disk space is allocated in the data area only when required and is accomplished in one allocation unit at a time. An allocation unit is referred to as a cluster and is represen- ted by one or more consecutive sectors. A sector is usually 512 bytes. A cluster will contain from 1 to x sectors depen- ding upon the media. Some typical allocations are: o Double sided floppies 2 sectors/cluster. o 10mb hard 8 sectors/cluster. o 20mb hard 16 sectors/cluster. This method of storage presents some problems to the user (especially those running BBS systems) who store many small files. Consider storing 100 files of text containing ap- proximately 200 bytes each file on a 10mb hard disk (Like Fido stores messages). Figuring 8 sectors/cluster X 512 bytes/sector = 4096 bytes per allocation unit. 100 alloca- tion units would be needed (providing each file only needs one allocation unit each) at 4K per representing 400K bytes of storage for 100 files. You are only actually storing 200 bytes X 100 files or 20K bytes of data ( a very big waste of space). DOS 3.1 attempts to solve this problem by allowing Fidonews Page 5 17 Feb 1986 the user to define the cluster size. Enough about problems, back to file storage techniques using the direct method (reference back Fido news issue). When information is written to the disk, the system looks for the cluster that is closest to the beginning of the data area and available. This criteria can easily be fulfilled by checking the FAT. The FAT maps every cluster of the data area and is in fact a large linked list to files occupying more than one cluster. FAT data is stored 1.5 bytes per cluster, with cluster #2 defined as the start of the data area. The first two FAT entries represent system data, entry 3 through X actually map the entire disk. The value of each FAT entry could be one of the following: o 000H Unused cluster. o 002H-ff6H Next cluster of data. o ff7H Bad cluster. o ff8H-fffH Last cluster of file. The root directory is initially built at the time of disk format. It is a fixed value of clusters depending upon the size of the media. Each directory entry is 32 bytes in length and contains information required by the system to locate files. Since directories other than the root direc- tory are actual files, there is no limit to the number of entries they may contain. Reference the DOS manual for a complete description of the fields of a directory entry. For now all that you should know is that fields 00-07H contain the file name, 08-0aH contain the extension, and 1a- 1bH contain the starting cluster number. The following brief discussion describes file access using the direct method (assume root directory only): 1. The media data is read to obtain the necessary informa- tion as to number of sectors, where the root dir starts, how big it is, etc. 2. The Root directory is read. 3. Each 32 byte entry is scanned until the correct file is located. 4. The starting cluster number at offset 1a/1bH of that directory entry is obtained and converted to logical sector number. 5. X number of sectors per allocation is read to a transfer address starting at the sector calculated above. (X sect/allocation unit is a function of the media). 6. Next the FAT map is checked to see if additional clusters must be read. This is accomplished by conver- ting the cluster just read from the directory entry to Fidonews Page 6 17 Feb 1986 an offset value into the FAT. If the 1.5 bytes represen- ting the starting cluster contains data pointing to additional clusters, the system will read that cluster. This next mapped cluster entry will be checked and the process will continue until the last cluster is read. The following visually represents the process: DIRECTORY (Entry #3) ___________________________________________________ | | | Name.ext | | | | 1 | 2 | start cluster---- | X | |_____|_____|_____etc.______|_|_________________|____| | ___________|______ | | _________| Routine to | | | access data | | |__________________| | _________|_ | | | | FILE ALLOCATION TABLE | ______2_|_____________5__________________________X__ | | | | | | | | | | sys | 5 | | FFF| | | | |_____|_____|________|____|_____________________|____| | |_____________| | |____ DATA AREA | _|__________________________________________________ | | | | | _ | | | | | 2 | 3 | | 5 | | X | | |_____|_____|___________|____|__________________|____| |___________________________| The conversion of cluster number to logical sector and determining the byte offest into the FAT is simple. The method is written in any DOS manual near the system calls section. One trick which is not mentioned is that the formula to determine offset into the FAT table will only work if you operate on the table as if each byte were an entry ( that is if you read the table as bytes, and not words). I hope this small article has been of some help to the readers in understanding some of the file storage techniques of the MSDOS operating system. One example of using this method of file access is depicted in the public domain 'C' program DSKRPK.ARC located on Fido 107/29. ------------------------------------------------------------ Fidonews Page 7 17 Feb 1986 Where Oh Where Can that Interrupt Be? I need some help, please. Maybe I am looking at the wrong elements in my system, but I have had a rash of communications problems lately. My system is a PCXT with a Hayes 1200b and fully populated Quadram Quadboard installed. My comm port is COM2: My problems is this: Since installing the Quadboard, I have had problems with telecommunications. I had installed the Quadram print spooler and clock device driver. When I would connect, the modem would return strange baud rate values, such as 20, or 120, etc. I am using Pibterm as a comm program. Removing the print spooler from CONFIG.SYS solved this, I think. Now, I occasionally will have connection problems. Connec- tion is made, the remote tone is audible, but my system doesn't respond. This is rare and may be an artifact of a noisy non-Bell long distance service. Modem testing revealed no problems. Could it be a problem with the clock driver? I have removed it from CONFIG.SYS and am only using the clock setting .EXE file in my AUTOEXEC.BAT. A colleague thinks it is a conflict between the interrupts used in the clock device driver and the communications system. If you have any ideas please let me know. If you know of a print spooler that doesn't cause problems with communica- tions, please let me know about it, too. Thanks for your help. Bill Allbritten, 11/301 ------------------------------------------------------------ Fidonews Page 8 17 Feb 1986 Two New Newsletters for Fidonet Fidonet PCNews and Fidonet Languages Fidonews is an excellent way of getting news and information across the network to both the sysops and users of Fido boards. The nature of the articles though usually relates to Fido itself or to BBS's in general. The articles are also written primarily by sysops, perhaps because of the restriction of file attaches to users with sysop or extra privileges. There is nothing really wrong with this focus of Fidonews, the newsletter serves a very needed purpose in the network. Something more is needed though. What I propose is a concept similar to the news groups of Usenet. I would like to see one or more new newsletters built from netmail messages instead of from file attaches, thus making the newsletters more accessible to all users. The content of each newsletter would be focused on one specific subject, not necessarily having anything to do with computers. As an experiment, I am going to try and get the first of these going from The Ark Tangent. The two newsletters I'm going to be putting together are Fidonet PCNews and Fidonet Languages. The first will be concerned with IBM PC's and clones, while the second will have programming languages as its focus. Getting information into the newsletters will be simple. Send a netmail message to node 137/19 addressed to the name of the newsletter you are contributing to, either Fidonet PCNews or Fidonet Languages. Weekly, on Tuesday morning, the mail for each newsletter will be converted to straight text and concatenated into a text file to be distributed across the network. Responses to the messages in the newsletters could be directed back to the newsletter or the author of the message, whichever suits. In order to receive the newsletter on your node you will need to poll The Ark Tangent (137/19) to pickup an archived copy of the file. Send me a note requesting one or both of the newsletters and I'll set you up to pick up the files on a weekly basis. Wes Cowley Sysop, The Ark Tangent Fido 137/19 ------------------------------------------------------------ Fidonews Page 9 17 Feb 1986 Encryption, Public Keys and Otherwise PART One. If you know what "Public Key Encryption" is then feel free to skip to part two. Public Key Encryption is a special form of encryption which uses different keys for encryption (or scrambling) of a message and decryption (unscrambling, the reverse operation). The separate keys for each operation have several advantages. The first is that the encryption key can be distributed much more easily by less secure means without compromising the security of future encrypted messages. Simple knowledge of the encryption key does not enable decryption of encrypted messages. The decryption key is required to recreate the original message. For this reason the encryption key is commonly called the "public key" and the decryption key is the "private key". In operation, everyone who wants to receive secret messages creates their own pair of keys, one private and one public. The public key is them communicated to everyone who may want to send them a secret message. Perhaps a central key distribution center could be established. The private key is kept secret and never told to anyone. For example ... Art wants to send Beth a secret message. He would look up Beth's public key or ask her to send him one (in the clear). He would then use Beth's public key to encrypt his message and send her the encrypted message. Beth receives the message and decodes it with her private key. No one else can decrypt the message even if they get a copy of the encrypted message AND the public key. They need the private key. In 1978 the CACM journal published a way of doing this on computers. The system they described has come to be known as the "RSA" encryption system. The RSA system has an additional property beyond the general Public Key Encryption system described so far. With the RSA system the keys are interchangeable so you can use a private key to encrypt a message and then only the corresponding public key will unscramble the message. This is in effect a "digital signature" which "signs" a message showing that the encrypted message could only have been created with knowledge of the private key. Messages can also be encrypted more than once. For example you can sign a message with your private key and then encrypt the result again with the intended receiver's public key to make a signed, secret message. The receiver would then need to do the reverse two steps in the reverse order to get the original message back. Fidonews Page 10 17 Feb 1986 Even more complex interaction can be used for special purposes. Articles have appeared on how to play poker over the phone and how to hold a secret ballot election over the phone and others. PART Two. I have recently completed a Public Key Encryption system based on the RSA system. It runs on MS-DOS using files for keys and messages. I am distributing the system as freeware/shareware. (PKSCrypt 0.0 or 0.01) There may be some legal or political considerations in this. I have heard rumors that this sort of stuff comes under certain restrictions for export of high tech (or something) from the USA. I don't think this quite applies to me because I am exporting the system TO the USA. (I live in Canada). I have also heard rumors that some intelligence organization (unnamed) is discouraging public discussion (let alone utilization) of these systems. I have trouble believing this because I had no trouble finding all the information I could ever desire on the subject. There was even an article in Byte magazine and a couple follow-up letters. Anyone who has any solid info on this, I would like to hear from you. I especially would like to hear directly from any government organization(s) (in any country) who may think they are involved. Interested parties may contact me via Fido node 134/1. Lloyd Miller Calgary, Alberta 1986 Janualry 16 ------------------------------------------------------------ Fidonews Page 11 17 Feb 1986 Thom Henderson, node 107/8 System Enhancement Associates XMODEM protocol benchmark SEA recently performed a series of benchmarks aimed at producing a formula for the realistic prediction of file transfer times. This report presents the results of that benchmark, along with some conclusions about the XMODEM protocol and file transfer protocols in general. The raw data for the benchmark was collected by transferring files of different sizes at different baud rates over local phone lines and timing the transfer periods. Files were transferred between a Fido BBS system and a PC running Minitel, using the XMODEM file transfer protocol with CRC error detection. No errors were reported during the transfers used in the benchmark study. The raw data may be summarized as follows: Transfer Times in Seconds 50 Blocks 100 Blocks ========= ========== 300 Baud 236.3 472.3 1200 Baud 71.1 142.5 2400 Baud 39.5 80.2 From this data we deduced the following formula for predic- ting file transfer times using integer variables: Blocks*1340 Blocks Time in seconds = ----------- + ------ Baud rate 4 For 50 blocks at 300 baud this would yield 50*1340/300 = 223 seconds, plus 50/4 = 12 seconds, for a total of 235 seconds. The formula varies with the measured times from being 2.6% low to being 3.8% high, with an average error of 0.5% low. This is considered to be within observational errors. Construction of the formula was primarily based on this assumption: that file transfer time will be split between the time required to send the 134 bytes per block that the protocol requires (we are including the ACK sent by the receiver), plus overhead time required for each block. This gives us a variable time dependent on baud rate, plus a fixed overhead which is independent of baud rate. The above formula is based on an overhead of 0.25 seconds per block. (The actual calculated figure was 0.27 seconds, but this is within observational error.) This overhead time can be Fidonews Page 12 17 Feb 1986 attributed to processing delays at either end, line "purge" time, and propagation delays. Propagation delays would be minimal in a local connection such as this, but would grow significant in a long distance connection involving satellite relays (at least an additional 0.25 seconds). Using a larger block size would help reduce this by reducing the number of blocks being transferred, as well as reducing the percentage of bytes used for the protocol. The percentage of slack time (based on the above formula) at different baud rates follows: Baud 128 byte blocks 1024 byte blocks ==== =============== ================ 300 5.3% 0.7% 1200 18.3% 2.8% 2400 30.9% 5.5% 4800* 47.3% 10.5% 9600* 64.3% 18.9% * Formula not backed by benchmark data at this speed. As you can see, the 128 byte block size is well suited to 300 baud transmission, and even acceptable at 1200 baud, but rapidly becomes onerous at higher baud rates. At first glance a larger block size seems to be an ideal solution, since time spent on overhead is acceptable even at the higher baud rates. It is my opinion that this is at least partly illusory. The above figures are calculated assuming a zero error rate. A connection that is even moderately noisy will produce enough "hits" to quickly eat up any improvements. Conclusion: If you can't lick 'em, join 'em. XMODEM protocol with CRC error detection achieves a trans- mission reliability on par with the best of the major data network services, but it suffers in transmission time at the higher baud rates. A solution that would be viable at any baud rate would be a "sliding window" protocol, something like the X.PC protocol. However, X.PC suffers from being excessively complicated, but it does have the advantage that TymNet has released sources for its implementation. It may not be necessary to go as far as a full X.PC imple- mentation. A sliding window algorithm based on a fixed block size should not be difficult to implement. ------------------------------------------------------------ Fidonews Page 13 17 Feb 1986 ============================================================ COLUMNS ============================================================ Notes from Abroad As I'm sure all you sysops have already found out, this Fido lark consumes a lot of time. On top of Fido I also run the Compulink User Group, this takes up most of my time, but I hope to be able to spend more time on the Fido side in the future. I started Compulink just over a year ago and from then I have been spending as much time as possible working for the group, promoting the public domain software concept, and also running Fido. There has always been more work than I could squeeze into a day, but, unfortunately not enough money was coming in to pay for itself. I have therefore been forced to go out to work in the day to subsidize Fido and the user group. I have got some pretty big plans for Fido and the user group (I consider the two inseparable!), but I don't have the money to see them through. When I have to go out to work I don't have enough time to work on both projects. Fortunately I have received a little press coverage in the last few months and this has brought in enough money for me to give up my day job. Now I'm not making a fortune, in fact most of the money that comes in is going straight out again, this is mainly because I underpriced all the fees I charge for the user group. Unfortunately I have to put up my prices for 86, if I don't do this I wont be here this time next year. It's still a very good deal joining Compulink, but next year I simply can't afford to subsidize membership out of my own pocket. In return for my higher fees I hope to be able to plow even more of my time into the project and everyone will benefit. The next major step I will take is to move into a small office. At the moment I am renting my house and the landlord won't allow me to install any more telephone lines. I am running two Fido's concurrently at the moment, eventually I hope to have about 6 incoming lines, a PSS data-line and a true multi-user Fido. This will cost a fortune but I'm going to do it, when I look at the services offered by Telecom Gold, Easylink, et al; I think, Hell, I could do better than that! As Fido gets more and more powerful (which of course it will!) I will be able to offer subscribers more and more for their money. What I'm waiting for now is true multi-user Fido, one that can support more than one input stream. The RBBS-PC bulletin board software (also public domain) has just gone multi-user, and I hope Fido will follow shortly. I am not expecting Tom Jennings to do this, TJ has done more than his share already, and if you haven't done so already; I think you should buy the Fido software from Tom as detailed in the new manual. Any further innovation has to come from us, the Fido sysops, Fidonews Page 14 17 Feb 1986 and of course our users. When a Fido clone has been officially accepted as the public domain Fido we can all start customizing our own Fido's to our own requirements. Till then we take what we get and thank our lucky stars that someone cares enough about what we are doing to make improvements. I'm sorry for going on like this, but I thought I'd tell you all how I feel. What I'm really trying to say is this; OK I charge people a fee or full access to my system, sure; I charge people a fee for copying disks. If you read on you'll see the charges I make, they're reasonable, I've also sent a copy of the disk magazine I write to all the country coordinators to do with what they will, I've also sent out my disk catalog. I REALLY believe in what I'm doing. If I could afford to do all the things I've been talking about I wouldn't be writing all this because I would have already done it! I don't think it's wrong to charge people for what I'm doing. It's the only way I can raise the capital needed to fulfill my plans. If you have any comments (good or bad) on the above I would welcome them. ------------------------------------------------------------ Fidonews Page 15 17 Feb 1986 ============================================================ FOR SALE ============================================================ FOR SALE OR TRADE! DEC 11/23 Minicomputer as follows: 11T23 Computer CPU card has MMU and FPU (2) RL01 5MB Removable Disk Drives (4) Disk Packs for RL01 LA-120 "DECwriter" printing terminal (2) 4 serial port "J" cards Latest version of RT-11M+ (5.1) Misc documentation This computer is about six years old, but was only used for about a year of that time, so it's had VERY little use. I'd be interested in: A cash offer Trade for: (1) ea IBM-PC/AT system or (2) ea DEC Rainbow (w/hard disk) systems or (1) ea grand piano This is available in Portland, OR and shipping would probably be prohibitive (extremely heavy, like a small refrig), but it's your nickel (FOB Portland). Contact me for further information: Doug Forman, Sysop MacSystem/NW 105/8 (503) 233-6583 BBS (503) 236-8160 Eves (503) 357-6151 x2295 Days ------------------------------------------------------------ Fidonews Page 16 17 Feb 1986 ENTERTAINMENT SOFTWARE FOR YOUR PC! SUPERDOTS! KALAH! Professional quality games include PASCAL source! From the author of KALAH Version 1.6, SuperDots, a variation of the popular pencil/paper DOTS game, has MAGIC and HIDDEN DOT options. KALAH 1.7 is an African strategy game requiring skill to manipulate pegs around a playing board. Both games use the ANSI Escape sequences provided with the ANSI.SYS device driver for the IBM-PC, or built into the firmware on the DEC Rainbow. Only $19.95 each or $39.95 for both exciting games! Please specify version and disk format. These games have been written in standard TURBO-PASCAL and run on the IBM-PC, DEC Rainbow 100 (MSDOS and CPM), CPM/80, CPM/86, and PDP-11. Other disk formats are available, but minor customization may be required. BSS Software P.O. Box 3827 Cherry Hill, NJ 08034 For every order placed, a donation will be made to the Fido coordinators! Also, if you have a previous version of KALAH and send me a donation, a portion of that donation will also be sent to the coordinators. When you place an order, BE CERTAIN TO MENTION WHERE YOU SAW THE AD since it also appears in PC Magazine and Digital Review. Questions and comments can be sent to: Brian Sietz at Fido 107/17 (609) 429-6630 300/1200/2400 baud ------------------------------------------------------------ Fidonews Page 17 17 Feb 1986 Daniel D. Stuhlman BYLS Fido (no node number yet) File Security and Secret*File Security is a frequent problem with computer use. If you have a large number of personal computer users who need to share files how do they insure that only the intended receiver reads the file? Secret*File from BYLS Press is a file encryption program for everyone who wants to share secure MS-DOS files. Secret*File is menu-driven and easy-to-use. Program requires an IBM-PC compatible computer with MS-DOS 2.1 or higher, 128K RAM, and one 5" disk drive. Examples of uses: 1. Send a coded file to a friend via modem. 2. Upload a coded file. Let a friend download it. 3. Put a coded file on a disk. Send disk to a friend. 4. Send coded messages from field offices to home office. Secret*File offers the following security features: 1. User name and password required to operate program. 2. User and receiver must know exact file name. 3. Two types of coding. 4. User may change random number files needed for coding. 5. File's password is not stored. 6. Decoy bytes and check digits make cryptoanalysis difficult. Secret*File codes and decodes at the rate of 50 bytes per second. Disk is not copy protected and may be used on a hard disk. Single copies of Secret*File cost only $75 and include a free copy of Print*File. Print*File is a printer control utility to allow use of the fonts offered on an Epson compatible printer. Quantity and dealer discounts and site licenses are available. A demo version and more information may be downloaded from BYLS Fido board 312-262-8959 (11 PM - 9 AM weekdays, all day Saturdays Central Time zone) Order or request more information from: BYLS Press 6247 N Francisco Chicago, IL 60659 ------------------------------------------------------------ Fidonews Page 18 17 Feb 1986 ============================================================ NOTICES ============================================================ The Interrupt Stack 22 Feb 1986 Submissions deadline for the CROBOTS competition. Ask Andy Foray at 107/7 for details. 1 Mar 1986 The Next Occasional MetroNet Sysop Meeting, to be held at Matt Kanter's apartment. Check with Matt at 107/3 for details. 1 Mar 1986 European mail hour shifts to 0230-0330 GMT. Summer time will no longer be observed. 11 Apr 1986 Halley's Comet reaches perigee. 19 May 1986 Steve Lemke's next birthday. 24 Aug 1989 Voyager 2 passes Neptune. If you have something which you would like to see on this calendar, please send a message to Fido 1/1. ------------------------------------------------------------ Fido 11/301, Fido Racer, Murray State University, and Fido 144/2, Fido CSU, Colorado State University, are interested in forming a network of FIDO's at institutions involved in advanced education -- colleges, universities, medical schools, institutes, and the like. If you are interested, drop a line to 11/301 expressing interest. We may be able to get some interesting exchanges going in an area that doesn't seem to be represented in a net at this time. We look forward to hearing from you. Bill Allbritten, sysop, 11/301 ------------------------------------------------------------ Net 107 has a New Host Due to our previous host's serious and ongoing phone line problems, Don Daniels is now the host for net 107, as of Fidonews Page 19 17 Feb 1986 node list #038. ------------------------------------------------------------ The Orange County section of NET 102 has broken out to a separate net. This change is effective as of node list 031. Our new net is 103. All the 500 series nodes from new 102 are now addressed as net 103 with the same node numbers. 103/501, Host of net 103 ------------------------------------------------------------ New Version of Rovermsg Available by Bob Hartman Sysop Fido 132/101 The UN*X Gateway and Home of Rovermsg Once again there is a new version of ROVERMSG available for downloading from my board. The new version is Revision 2.16. This version has some small bug fixes, and also allows faster video display on IBM PC's, DEC Rainbows, and Sanyos. The new video display is about 2-3 times faster than it used to be. Anyone who is using a previous version of Rovermsg should update to the new version if possible. ------------------------------------------------------------ Fidonews Page 20 17 Feb 1986